斜線指令會改變 Codex 的工作狀態

在 Codex 輸入框中鍵入 /，畫面會列出目前可以使用的斜線指令（slash command）。

一般提示內容負責交代要完成的工作，斜線指令則由 Codex 介面處理，用來切換模式、保存目標或啟動特定流程。

例如輸入 /plan 後，Codex 會先規劃。輸入 /review 後，它會進入程式碼審查流程。

今天會使用 Codex 命令列介面（Command-Line Interface, CLI）操作 codex-hands-on 專案。因為雖然 Codex 網頁版也有 / 選單，但網頁版不提供完整的 Codex CLI 指令集。

IDE 擴充功能與 Desktop 可見的指令也會受到版本與目前畫面影響。我們可以在輸入框鍵入 /，以確認目前版本可使用的指令清單。

這次固定任務是修正標籤統計的大小寫問題。當一筆議題（issue）帶有 Bug 或 SECURITY 標籤時，程式目前沒有將它計入 bug 或 security。

預期規則是四種目標標籤採用不分大小寫的比對，輸出的標籤名稱與格式維持原狀。整個操作會依序使用 /plan、/goal 與 /review。

「Codex 開發者指令官方說明」列出各個 CLI 斜線指令的用途與操作方式。指令會隨版本更新，若文章中的說明已經與實際操作不同，可以先確認 Codex CLI 版本，並查看目前的官方清單。

準備專案與確認指令可用

先在終端機進入 codex-hands-on，確認目前分支與工作目錄。這次任務需要修改程式與測試，開始前應先處理其他尚未提交的內容。

乾淨的 Git 狀態可以讓 /review 聚焦在這次工作，避免審查結果混入人工修改或其他任務留下的檔案。

cd codex-hands-on
git branch --show-current
git status --short
codex

Codex 開啟後，在輸入框鍵入 /，確認清單中能看到 /plan、/goal 與 /review。若某個指令沒有出現，先使用另一個終端機執行 codex --version，再依官方安裝方式更新 CLI。

工作階段（session）已經在執行任務時，/plan 會暫時無法使用，因此要等目前工作停止後再切換模式。

接著查看 Git 狀態與修改前的測試結果。若專案測試已經失敗，先記錄失敗項目，確認是否和標籤統計有關。

目前的假設基準是測試通過，後面會用相同命令驗證修正。這些準備也能提供 /review 清楚的比較起點。

用 /plan 先建立修正步驟

在 Codex CLI 輸入 /plan 並按下 Enter，工作階段會切換到計畫模式。也可以在同一行附上任務內容，讓 Codex 直接開始分析。

計畫模式允許 Codex 讀取專案、提出問題與整理步驟。此時先把注意力放在問題位置、修改範圍與驗證方式。

/plan 請規劃修正標籤統計的大小寫問題。

目前 Bug、FEATURE、Documentation、SECURITY 等大小寫不同的標籤，沒有計入 bug、feature、documentation、security 的對應統計。

預期四種目標標籤採用不分大小寫的比對。保留原有輸入資料、輸出標籤名稱、輸出順序、排名與 priorityScore 行為。

請找出相關實作與測試，列出預計修改的檔案、修正方法、測試案例與驗證命令。
先提供計畫，不要修改檔案，也不要新增套件。

收到計畫後，要核對 Codex 是否把大小寫正規化放在統計邏輯內，並保留原始資料。

測試應包含至少一個大小寫混合的標籤，也要保留小寫標籤與非目標標籤的既有行為。若計畫提到修改命令列輸出、資料來源或相依套件，應要求它說明必要性並縮小範圍。

/plan 可以搭配內嵌提示內容，也可以先切換模式，再輸入完整需求。要提醒的是，Codex 正在工作時無法臨時切入計畫模式，因此應在修改開始前完成規劃與確認。

用 /goal 保存這次工作的方向

計畫確認後，輸入 /goal 設定這個工作階段要維持的目標。

目標適合保存多輪對話中都要遵守的結果與限制。它不需要重複完整問題分析，只要留下可判斷完成與否的方向。本文將大小寫規則、行為限制與測試要求放入同一條目標。

/goal 修正四種標籤統計的大小寫比對，保留現有輸入、輸出、排名與 priorityScore 行為。只修改直接相關的實作與測試，完成前必須通過相關測試及完整測試。

設定後，可以輸入 /goal 查看目前內容。執行途中發現範圍需要調整時，可用 /goal edit 編輯。暫時停止工作可用 /goal pause，繼續時使用 /goal resume。

任務結束後，則用 /goal clear 清除，避免下一項工作沿用已經失效的方向。

/goal 會把目標附在目前工作階段中，細部修正步驟仍由已確認的計畫與後續提示提供。

若目標只寫「修好標籤」，Codex 很難據此判斷哪些行為需要保留。寫入可驗證的結果與範圍後，每次修改與測試都能回到同一組條件檢查。

切回執行模式並完成修改

確認計畫與目標後，使用 /plan 切回一般執行模式，再用一般提示內容授權修改。

送出前可以查看畫面上的模式標示，確認目前已離開計畫模式。這一步會把前面核對過的步驟轉成實際工作，Codex 可以編輯檔案，並執行允許的專案命令。

請依照剛才確認的計畫執行修改。

四種目標標籤採用不分大小寫的比對，輸出的標籤名稱與順序維持原狀。
請補上大小寫混合、原有小寫與非目標標籤的測試。
不要修改其他功能、README、部署設定或套件相依，也不要建立提交。

完成後執行相關測試與專案既有的完整測試，列出實際命令與結果。

執行期間若 Codex 發現計畫中的檔案位置有誤，可以讓它更新路徑並說明原因。若需要改變公共介面或輸出格式，應先停下來確認。

/goal 會留在工作階段中，開發者仍要閱讀每次工作紀錄與權限要求，避免無關操作混入任務。

修改完成後，先查看測試輸出。大小寫混合案例要證明 Bug、FEATURE、Documentation 與 SECURITY 能進入對應計數，原有小寫案例要維持結果，非目標標籤則不應影響四種統計。

若 Codex 修正程式後又調整測試，每輪修改都要重新執行約定的檢查。

用 /review 啟動差異審查

測試通過後，在 Codex CLI 輸入 /review。依目前版本顯示的選項，選擇審查未提交變更，讓 Codex 讀取已暫存、未暫存與未追蹤檔案。若要檢查整個分支相對於基準分支的差異，也可以選擇分支比較範圍。

目前我們尚未建立提交，因此使用未提交變更。

/review

Codex 會啟動專用的審查流程，集中尋找行為變更、回歸風險與測試缺口。這個流程只會回報發現，不會直接修改工作目錄。

審查結果要能回答幾個具體問題：正規化是否只影響標籤比對、原始 issue 是否被改寫、非字串或空值沿用哪些既有行為，以及新增測試是否覆蓋大小寫混合情境。

/review 可以審查未提交內容、指定提交，或相對於基準分支的差異，也能加入自訂審查條件。審查範圍會反映 Git 儲存庫目前存在的全部變更，因此內容不會只包含 Codex 最近修改的部分。

用 /diff 核對實際變更

/review 提供風險判斷，開發者仍要閱讀實際差異。審查完成後輸入 /diff，查看各檔案新增與刪除的內容。

也可以另開終端機執行 git status --short 與 git diff，核對修改檔案、程式碼與測試，確認摘要和工作目錄一致。

/diff

這次差異應集中在標籤統計函式與相關測試。實作可以先將目前標籤轉成統一大小寫，再與四個目標名稱比較，原始標籤資料應保持不變。

若差異包含其他的調整，便需要確認原因，並移除無關變更。找到問題時，可以用一般提示要求 Codex 修正指定項目，接著重跑測試，再次執行 /review 與 /diff。

審查意見也要由開發者核對程式與需求。沒有證據的推測，可以要求 Codex 提供檔案位置、觸發條件與影響結果，再決定是否修改。

清除目標並完成這次工作

測試、審查與差異都確認後，輸入 /goal 再看一次目前目標，逐項核對結果。

四種標籤應能接受不同大小寫，輸出格式與排名行為維持原狀，變更範圍只涵蓋直接相關實作與測試。完成這些檢查後，使用 /goal clear 結束目標。

/goal
/goal clear

清除目標不會刪除程式修改、對話或測試紀錄，只會移除目前工作階段附帶的持續目標。

接著可以依團隊流程保留修改、建立提交或交給其他成員審查。若任務仍有失敗測試或未處理的審查意見，先保留目標，完成修正與再次驗證後再清除。

這次操作將三個指令放進同一段工作節奏：/plan 在動手前整理修改路徑，/goal 保存多輪對話中的完成條件，/review 在修改後檢查差異與風險。

一般提示內容繼續負責需求細節與執行指示，斜線指令則協助開發者控制 Codex 當下採用的工作狀態。

參考資料：

• Codex 開發者指令官方說明